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Abstract 

Several  works  have  recently  shown  that  Android’s  security  architecture  cannot  prevent  many  undesired 
behaviors  that  compromise  the  integrity  of  applications  and  the  privacy  of  their  data.  This  paper 
makes  two  main  contributions  to  the  body  of  research  on  Android  security:  first,  it  develops  a  formal 
framework  for  analyzing  Android-style  security  mechanisms;  and,  second,  it  describes  the  design  and 
implementation  of  SORBET,  an  enforcement  system  that  enables  developers  to  use  permissions  to  specify 
secrecy  and  integrity  policies.  Our  formal  framework  is  composed  of  an  abstract  model  with  several 
specific  instantiations.  The  model  enables  us  to  formally  define  some  desired  security  properties,  which 
we  can  prove  hold  on  SORBET  but  not  on  Android.  We  implement  SORBET  on  top  of  Android  2.3.7,  test 
it  on  a  Nexus  S  phone,  and  demonstrate  its  usefulness  through  a  case  study. 


1  Introduction 

Recent  years  have  witnessed  an  explosion  in  the  use  of  mobile  computing  thanks  to  the  proliferation  of 
feature-rich  smartphones,  and  associated  app  stores  and  easy-to-install  applications.  Smartphones  have 
powerful  hardware,  with  many  useful  sensors  (e.g.,  GPS,  camera,  microphone,  accelerometer)  exposed  via 
rich  APIs,  and  enough  computing  power  to  run  complex  applications.  Applications  take  advantage  of  these 
rich  APIs  to  perform  convenient  and  useful,  but  potentially  privacy-sensitive  tasks  such  as  accessing  address- 
book  or  location  information;  accessing  online  banking  and  medical  accounts;  and  controlling  home  security 
systems.  App  stores  make  it  easy  for  users  to  install  and  run  applications,  while  providing  few  guarantees 
about  their  provenance  or  behavior. 

To  protect  sensitive  resources  from  applications,  and  applications  from  each  other,  Android  and  other 
mobile  OSes  implement  security  mechanisms  such  as  permission  systems  and  strong  isolation  between  ap¬ 
plications.  These  mechanisms,  however,  have  in  practice  proved  insufficient,  with  an  increasing  number  of 
malicious  applications  starting  to  target  smartphones  [14,  22,  15]. 

A  number  of  works  have  investigated  these  weaknesses  from  various  perspectives,  including  demonstrating 
how  applications  can  communicate  through  covert  channels  [23,  17],  developing  tools  to  detect  information 
leaks  [8,  5,  13],  and  implementing  more  powerful  protection  mechanisms  (e.g.,  [21,  19,  7,  2]). 

This  paper  adds  to  the  body  of  research  on  Android  security  in  two  main  ways:  first,  by  developing 
a  formal  framework  for  analyzing  Android-style  security  mechanisms,  including  defining  properties  desired 
of  those,  and  verifying  whether  these  properties  hold;  and,  second,  by  designing  and  implementing  an 
enforcement  system  that  provides  application  developers  with  simple  language  constructs  to  specify  flexible 
secrecy  and  integrity  policies,  and  provably  exhibits  desirable  security  properties.  To  remain  practically 
relevant,  we  constrain  our  enforcement  system,  which  we  call  Sorbet,  to  be  easily  retrofittable  into  Android’s 
current  architecture.  The  design  and  implementation  of  Sorbet  improves  existing  Android  permission 
system  in  the  following  aspects:  (1)  we  formally  state  the  properties  that  we  wish  our  new  mechanisms  to 
achieve,  and  formally  prove  that  our  system  design  supports  them;  (2)  we  enhance  Android’s  permission 
system  to  support  coarse-grained  secrecy  and  integrity  policies;  and  (3)  we  provide  more  flexible  support  for 
fine-grained  and  scope-limited  delegation  of  permissions. 

Formal  analysis.  One  of  our  main  goals  is  to  improve  our  understanding  of  the  security  properties  that 
we  desire  of  Android-like  permission  systems,  and  to  verify  that  specific  systems  are  capable  of  specifying 
and  enforcing  desired  properties.  We  pursue  this  goal  by  building  a  generalized,  abstract  model  of  the 
Android  permission  system,  and  stating  a  set  of  desirable  properties  in  terms  of  the  model.  We  then  develop 


1 


instantiations  of  this  model  both  for  the  current  Android  permission  system  and  for  Sorbet.  Based  on  this 
formal  account,  we  study  the  properties  of  the  current  system;  our  investigation  reveals  both  design  and 
implementation  flaws,  which  guide  the  design  of  Sorbet.  We  also  prove  that  Sorbet’s  design  is  sufficient 
to  support  the  properties  that  we  have  defined. 

Coarse-grained  secrecy  and  integrity  policies.  Sorbet’s  key  innovation  is  coarse-grained  mechanisms  that 
allow  developers  to  protect  their  applications  against  privilege  escalation  and  undesired  information  flows 
(e.g.,  [6,  8]).  Android’s  permission  system  only  prevents  applications  that  do  not  have  the  correct  permissions 
from  directly  calling  a  protected  component.  This  is  inadequate  to  protect  against  a  malicious  application 
that  reaches  a  protected  component  indirectly,  via  a  chain  of  calls  to  innocent  applications.  To  protect 
against  such  attacks,  we  enrich  Android’s  permission  system  with  the  ability  to  specify  information-flow 
constraints  and  explicit  declassification  permissions,  and  implement  a  light-weight  calling-context  tracking 
and  checking  mechanism.  A  key  challenge  here  is  to  support  local  specification  of  global  properties. 

Flexible  and  fine-grained  delegation.  Run-time  delegation  of  (URI)  permissions  is  a  key  feature  in  Android, 
and  allows  applications  to  use  third-party  components  (e.g.,  a  viewer  activity)  to  manipulate  content  that 
those  components  normally  would  not  be  permitted  to  access.  On  examination,  we  discovered  that  Android’s 
implementation  of  permission  delegation  is  plagued  by  a  number  of  flaws  and  questionable  design  decisions. 
Sorbet  supports  more  flexible  and  principled  permission  delegation  and  revocation,  and  allows  developers 
to  specify  constraints  that  limit  the  lifespan  and  redelegation  scope  of  the  delegated  permissions.  Developing 
a  mechanism  that  correctly  enforces  lifetime  and  scope  constraints  turns  out  to  be  unexpectedly  tricky, 
due  to  redelegation  and  the  dynamic  nature  of  Android  applications  and  components,  including  application 
installation  and  uninstallation,  and  instantiation  and  termination  of  components. 

Contributions  and  Roadmap  This  paper  makes  the  following  contributions: 

•  We  develop  a  formal  model  that  generalizes  Android-style  permissions  (§2.2).  We  show  how  Android’s 
current  permission  system  can  be  represented  as  an  instantiation  of  our  abstract  model  (§2.3). 

•  Building  on  this  model,  we  define  a  set  of  security  properties  that  one  may  desire  of  Android-style  per¬ 
mission  systems  (§3.1).  We  show  that  Android  currently  obeys  some  of  the  desired  security  properties, 
but  not  others,  and  expose  several  design  inconsistencies  and  implementation  flaws  (§3.2). 

•  We  describe  Sorbet,  a  set  of  improvements  to  Android’s  permission  system  that  supports  developer- 
specified  coarse-grained  information-flow  and  privilege-escalation  policies.  We  formalize  Sorbet  as  an 
instantiation  of  our  model  and  show  that  it  better  supports  the  desired  security  properties  (§4). 

•  Finally,  we  implement  Sorbet  on  top  of  Android  2.3.7,  test  it  on  a  Nexus  S  phone,  and  demonstrate 
several  new  scenarios  that  it  enables  (§5). 

2  Preliminaries 

We  first  review  the  Android  architecture  as  it  pertains  to  permissions  (§2.1).  We  then  develop  an  abstract 
model  of  Android-style  permission  systems  (§2.2),  and  an  instantiation  of  it  that  captures  details  of  Android’s 
implementation  (§2.3). 

2.1  Android  Overview 

Android  is  a  Linux-based  open-source  OS  designed  for  smartphones.  Android  applications  are  written  in 
Java  and  compiled  to  Dalvik  bytecode.  Each  application  is  executed  in  a  separate  Dalvik  Virtual  Machine 
(DVM)  instance. 

Android  applications  are  composed  of  four  types  of  components: 

Activities  define  the  user  interface.  Only  one  activity  interacts  with  the  user  at  a  time.  Users  typically 
interact  with  a  sequence  of  activities  to  perform  a  task. 
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Services  run  in  the  background  and  have  no  user  interface.  Unlike  activities,  services  remain  active  regardless 
of  which  application  is  in  the  foreground. 

Broadcast  receivers  listen  for  system-wide  broadcasts,  and  inform  other  application  components  upon  the 
receipt  of  a  broadcast. 

Content  providers  store  data  and  are  the  main  way  to  share  data  between  applications.  Each  provider  exposes 
a  public  URI  that  uniquely  identifies  its  data  set.  Components  and  applications  can  access  or  update  the 
data  via  SQL  queries. 

Activities,  services,  and  broadcast  receivers  communicate  via  intents,  asynchronous  messages  that  deliver 
data  and,  if  needed,  cause  a  new  instance  of  the  recipient  component  to  be  created.  The  OS  mediates  both 
cross-  and  intra-application  communications  via  intents.  The  recipient  of  an  intent  can  be  specified  explicitly 
by  its  package  and  class  name,  or  implicitly  via  the  action  the  intent  attempts  to  initiate.  We  will  often  write 
that  a  component  calls  another  component  in  lieu  of  explaining  that  the  communication  is  via  an  intent. 

Android  uses  (application)  permissions  to  protect  components  and  sensitive  APIs.  Permissions  are  strings 
defined  by  the  system  (e.g.,  android. permission. INTERNET)  or  declared  by  applications.  A  component  (or  API) 
protected  by  a  permission  can  be  accessed  only  by  applications  that  hold  this  permission.  An  application 
can  acquire  (application)  permissions  only  at  install  time,  with  the  user’s  consent. 

Additionally,  content  providers  can  use  URI  permissions  to  grant  ad-hoc  access  to  specific  pieces  of  data 
that  they  control  (records,  tables,  or  databases).  URI  permissions  can  be  dynamically  granted  and  revoked. 

2.2  Abstract  Model 

To  be  able  to  formally  state  the  properties  desired  of  a  permissions  architecture,  we  develop  an  abstract, 
formal  model  of  Android-style  permissions  systems.  The  model  comprises:  (1)  static  elements,  which  are  the 
code  and  data  we  want  to  protect;  (2)  run-time  elements,  such  as  system  events  and  component  instances; 
and  (3)  a  transition  system  that  captures  the  behavior  of  the  protection  mechanisms.  The  model  is  more 
general  than  Android’s  implementation  as  its  purpose  is  to  encompass  a  wider  design  space  of  permission 
systems,  including  previously  suggested  extensions  (e.g.,  [21]).  Fig.  1  shows  the  model’s  static  and  run-time 
elements. 

Static  constructs  Following  Android,  applications  in  our  model  are  built  from  components.  We  dis¬ 
tinguish  between  code  components  (Ccode)  and  data  components  ( Cdata )•  Code  components — activities, 
services,  and  broadcast  receivers — may  act  both  as  callers  and  as  callees,  while  data  components — content 
providers — are  passive  and  only  receive  calls.  A  code  component  is  comprised  of  a  name  (name),  the  actions 
A  to  which  the  component  is  willing  to  respond,  permissions  (Vdech  Vreq,  and  Vgrnt ),  and  guards  ( tfickCaiiee > 

( PckCaller )• 

In  Android,  calls  to  a  component  are  guarded  by  a  permission  check.  We  generalize  this  check  to  an 
abstract  guard  modeled  by  a  boolean  function  <pckCaiier •  For  now,  we  specify  only  that  ipckCaiier  takes  as 
arguments  a  component  and  the  calling  context  and  returns  true  or  false.  A  second  general  guard,  <pckCaiiee > 
specifies  when  outgoing  calls  should  be  allowed. 

We  distinguish  between  permissions  that  are  declared  ( Vdeci ),  requested  from  the  user  ( Vreq ),  and  granted 
(Vgmt)-  This  allows  us  to  model  behaviors  such  as  dynamic  delegation  of  permissions. 

We  model  applications,  C,  as  a  set  of  components  ({C\,  ■  ■  ■  ,  Cn } )  with  guards  and  permissions  that  apply 
to  all.  This  is  consistent  with  Android,  where  permissions  are  typically  declared,  requested,  and  granted  at 
the  application  level,  but  individual  components  can  protect  themselves  with  additional  permissions. 

Run-time  constructs  It  is  important  to  distinguish  static  components  from  run-time  instances,  and  run¬ 
time  instances  from  each  other.  A  static  component  C  may  have  multiple  run-time  instances  iC ,  composed 
of  a  unique  identifier  (e.g.,  pointer),  namer,  and  the  permissions  Vgrnt  granted  to  this  instance.  We  similarly 
model  run-time  component  groups  iC  (e.g.,  a  running  application). 

Principals  Prin  are  entities  that  can  grant  and  revoke  permissions:  run-time  components  and  component 
groups,  and  the  user  (i.e. ,  human  who  installs  applications).  Targets  Tgt  are  the  objects  of  such  operations, 
and  can  be  either  run-time  or  static  components  or  component  groups. 


3 


Static  Constructs 

Components 

C 

•  Ccode  |  Cdata 

Code  Components 

Ccode 

:=  (  name ,  A,  PckCallee  >  P ckCaller ,  P decl ,  P req  ,  P grnt ) 

Data  Components 

Cdata 

[name,  pckC alter,  P decl) 

Component  Groups 

6  : 

•  ( name ,  PckCallee >  P  ckCaller ,  P  decl,  P  req ,  P  grnt ,  {  C±  , 

,  Cn}) 

Run-time  Constructs 

Run-time  Instances 

Ins 

:=  iC  |  iC 

Comp  Instances 

iC  : 

:=  [namer,  C,Pgmt) 

Comp  Group  Instances 

iC  : 

~  {namer,C,Pgmt,  {zCi,  •  •  •  ,  iC„}) 

Principals 

Prin 

:=  Ins  |  user 

Targets 

Tgt  : 

:=  Ins  |  C  |  6 

Events 

E  : 

:=  x  =  Ei;  E2  \  call  zCi  iC2  I  return  zCi  ZC2  /  j  resolve  iC 

grant  Prin  Tgt  P  T  \  revoke  Prin  ({  Tgt1,  ■  ■  ■  ,  Tgtn 

})  P 

checkguard  iC  Tgt  p  |  exit  Ins  |  install  Prin  C  \  uninstall  Prin  C 
Figure  1:  Syntax  of  permission  model 


Abstracting  detail,  we  focus  on  system  events  that  concern  permissions,  such  as  component  communica¬ 
tion  via  intents  (call  iC\  1C2  /),  and  granting  (grant)  and  revoking  permissions  (revoke). 

We  allow  the  sequencing  of  two  events  using  x  =  E2.  The  event  Ei  is  executed  first,  and  produces 

a  result,  which  substitutes  x  in  i?2- 

The  event  call  iC\  1C2  I  models  a  component  iCi  attempting  to  call  1C2  with  intent  I.  When  1C2  is  a 
code  component,  this  models  the  last  step  of  starting  an  activity,  service,  or  broadcast  receiver.  When  zC^ 
is  a  data  component,  this  models  querying  or  updating  the  data  component.  Similarly,  *62  can  be  a  Java  or 
Android  API  method  protected  by  a  permission.  We  model  a  return  from  a  call  as  return  iC\  1C2  /,  where 
/  is  the  intent  that  conveys  the  value  returned  by  zC*2  to  iC-\ . 

The  resolve  iC  p  event  returns  a  run-time  component  that  satisfies  the  specification  p.  For  instance,  the 
following  macro  models  the  sequence  of  events  generated  by  iC  starting  an  activity  by  specifying  an  action 
A:  ( x  =  resolve  iC  pa',  call  iC  x  I).  The  guard  pa ,  defined  in  §2.3,  returns  true  if  the  set  of  accepted  actions 
declared  by  x  includes  A. 

Event  exit  Prin  signals  the  termination  of  a  run-time  component  or  group. 

Events  grant  and  revoke  model  granting  and  revocation  of  permissions.  A  permission  P  is  granted  or 
revoked  by  a  principal  Prin  to  or  from  a  target  Tgt  or  set  of  targets.  Granting  is  additionally  described  by  a 
flag  T,  which  constrains  the  lifespan  and  redelegation  scope  of  the  delegated  permissions.  We  discuss  these 
constraints  further  in  §2.3  and  §4.1  when  we  focus  on  the  Android  instantiation  of  the  abstract  model  and 
our  enhancements. 

A  component  can  also  check  whether  another  component  (group)  satisfies  a  specific  guard  p  using 
checkguard  iC  Tgt  p.  This  is  a  generalization  of  the  permission-checking  operation  in  Android. 

Finally,  we  model  the  installation  and  uninstallation  of  an  application  via  the  install  and  uninstall  events. 

Transition  system  We  capture  the  dynamics  of  the  model  as  a  transition  system.  We  model  a  system 
state  E  as  a  tuple  composed  of  a  set  of  entities  (run-time  and  static)  and  auxiliary  data  structures  Aux. 
We  write  8  to  denote  a  sequence  of  events  to  be  processed  by  the  system.  We  assume  that  each  event  is 
associated  with  a  unique  event  ID  n.  The  evolution  of  the  system  is  a  series  of  transitions  (E;£  E';  £'), 

where  o  records  whether  the  evaluation  of  event  n  is  successful  (o  =  ok(n))  or  fails  (o  =  fail(n)).  Evaluation 
of  a  call  event  will  fail,  for  example,  if  the  appropriate  guards  do  not  evaluate  to  true.  A  trace,  denoted  by 
T,  is  a  sequence  of  transitions:  Eo;  £0  Ei;  £\  ■  ■  ■  E&;  £*,. 

Most  of  the  specific  rules  in  the  transition  system  depend  on  the  concrete  implementations  being  modeled. 
Here  we  show  the  rules  for  resolving  an  instance  and  calling  a  component,  which  are  the  same  for  both  of 
the  instantiations  we  model,  except  for  detailed  operations  on  the  auxiliary  data  structures. 

The  resolve  event  updates  the  state  to  E',  and  returns  a  run-time  instance  iC2  that  satisfies  the  guard  p 
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under  the  updated  state  S'. 

RESOLVE-T  (E \£,n  ::  ( x  =  resolve  iCi  p\E ))  — ^  (E ';£,n'  ::  E[iC2/x] ) 

where  <p( E',  iCA  =  true  and  S'  =  updateResolve( E,  resolve  iCi  <p) 

For  brevity,  we  abstract  away  the  details  of  the  function  updateResolve(T,,re solve  zCi  y>).  This  update 
will  include,  if  needed,  creating  the  run-time  instance  iC2-  A  similar  rule  describes  the  scenario  when  resolve 
fails  and  the  output  of  the  transition  is  fail(n). 

Below  is  the  rule  schema  for  a  successful  call  event.  The  call  succeeds  only  if  both  guards  evaluate  to 

true. 

CALL-T  (S;  £,n  ::  call  iCi  iC2  I )  °-^  (E';£)  where  S'  =  updateCall( S,call  iCi  iC2  I) 
if  iC2.tpckCaiier{ E,  iCi)  =  true  and  iCi.ipckCaiiee(E,  iC2)  =  true 

A  parallel  rule,  CALL-F,  specifies  that  a  call  fails  if  either  guard  returns  false. 

CALL-F  (E;£,n  ::  call  iCi  iC2  I)  (E;£) 

if  iC2.<pckcaiier( El,  iCi)  =  false  or  iCi.tpckCaiUe(E,  iC2)  =  false 

A  call  event  fails  (rule  CALL-f)  if  one  of  the  guards  specified  by  the  caller  and  the  callee  fails  (evaluates 
to  false). 

2.3  Android  Model 

We  instantiate  our  abstract  model  to  describe  the  key  behaviors  of  Android’s  permission  system1.  This  has 
helped  us  to  identify  flaws  in  its  implementation  and  peculiarities  in  its  design.  We  discuss  in  detail  the 
guards  used  for  checking  permissions,  the  transition  rules  for  granting  and  revoking  permissions,  and  how 
events  such  as  application  exit  and  phone  reboot  affect  permissions. 

Guards  The  Android  permission  system  uses  four  guards,  which  we  label  ptrue ,  Pa,  'Pv  and  p^P . 

The  guard  ptrUe  always  returns  true,  and  is  used  when  access  is  unrestricted,  e.g.,  as  PckCallee  f°r 
components  that  do  not  broadcast  messages  (and  hence  need  not  restrict  their  recipients). 

The  guard  pa  is  used  by  resolve  when  a  call  is  described  by  an  action  (e.g.,  ACTION_CALL),  rather  than 
being  sent  to  a  specific  component.  pA(iC,T,)  returns  true  if  iC  accepts  action  A. 

The  guard  pp  checks  whether  a  component  is  granted  at  install  time  all  permissions  in  V.  pp  can  be 
used  as  pckCaiier  when  V  is  the  set  of  permissions  protecting  a  component,  or  as  PckCallee  by  components 
that  want  to  make  sure  that  their  sensitive  broadcasts  are  not  broadcast  too  widely.  To  define  pp,  we  first 
define  functions  to  look  up  the  permissions  associated  with  a  run-time  component  from  the  current  state. 
Function  grantedByUsrPerm{iC ,  E)  returns  permissions  granted  at  install  time.  Then,  we  can  define  pp  as 
follows. 

Pp  =  f(iC,  S)=?C  grantedByUsrPerm(iC ,  S) 

The  guard  p^"1  checks  whether  a  component  has  the  URI  permissions  specified  in  V.  pAd1  can  be  used 
as  p ckCaiier  when  V  is  the  set  of  URI  permissions  protecting  a  component. 

We  define  function  URIPerm(iC ,  E)  returns  the  URI  permissions  dynamically  granted  to  iC;  URIPerm 
in  turn  relies  on  a  data  structure  M.  to  track  the  URI  permissions  granted  to  each  application.  Then,  we 
define  p p”  as  follows. 

pum  a  £)  =  V  C  grantedByUsrPerm(iC ,  £)  U  URIPerm{iC ,  E) 

Granting  permissions  URI  permissions  can  be  granted  temporarily,  via  an  intent,  or  permanently,  via 
grantllriPermission.  We  model  the  former  as: 

grant  iC\  iC2  P  .Ftmp;  cal  I  iC\  1C2  /. 

1When  we  refer  to  Android,  we  mean  version  2.3.7,  which  was  the  newest  version  available  while  we  were  carrying  out  our 
investigation.  The  behaviors  we  describe  generally  hold  in  4.0  as  well. 
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Here,  iC\  grants  permission  P  with  flag  Ttmp  to  iCi  before  transferring  control  to  iCi-  Granting  permanently 
we  model  as  grant  %C\  C  P  Pvrm-  Flags  Ptmp  and  Tprm  constrain  the  lifetime  of  the  delegation  of  P  and 
the  scope  of  its  potential  redelegation  by  iC^-  Mirroring  Android,  the  lifetime  of  permissions  granted  with 
Ftmp  is  confined  to  the  lifetime  of  the  recipient  (tC?)  of  the  grant  operation.  When  granting  with  Pprm, 
the  recipient  will  have  the  permission  until  the  system  reboots  or  the  permission  is  revoked.  Neither  flag 
restricts  the  scope  of  redelegation.  The  following  rule  shows  how  grant  currently  works  in  Android. 

GRANT-TMP-T  (E; £,  n  ::  grant  iCj  iCi  P  Ptmp)  — ^  (£';£)  if  tp*py(iCi,  E)  =  true 

where  E'  =  updateGrant(E,  iCi,  iC2,P,Pt.mp) 

Granting  succeeds  only  if  the  granter  has  permission  P.  Afterwards,  updateGrant  updates  state,  by  recording 
in  M.  that  the  enclosing  application  of  1C2  now  has  permission  P  with  flag  Ptmp,  and  that  the  instance  zC^ 
has  P  in  Vgrnt. 

The  rule  for  granting  with  Pprm  (omitted  here)  differs  only  in  its  update  function:  M.  records  that  now  C 
has  permission  P  with  the  flag  Tprm ■  These  rules  make  explicit  that  Android  does  not  distinguish  between 
Ptmp  and  Pprm  when  deciding  whether  a  component  can  grant  permissions.  This  causes  problems  when 
components  redelegate  permissions,  as  we  discuss  in  §3.2. 

Revoking  permissions  Revocation  in  Android  is  coarse-grained:  permissions  can  be  revoked  by  their 
owner  and  by  any  applications  that  are  granted  the  permissions  at  install  time,  and  revocation  indiscrimi¬ 
nately  removes  the  permission  from  all  entities  which  had  it.  There  is  no  way  of  revoking  permission  from 
just  a  specific  application  or  component.  We  write  *  to  denote  all  run-time  instances. 

REVOKE  (E;£,n  ::  revoke  iC\  *  P)  (£';£) 

if  ipv{iCi,  £)  =  true  where  E'  =  updateRevoke( E,  *,  P) 

The  function  updateRevoke(T,,  *,  P)  removes  all  entries  related  to  P  from  Af,  and  removes  P  from  the 
granted  permission  set  of  all  run-time  components. 

Exit  and  Reboot  When  a  component  exits,  the  URI  permissions  that  it  was  granted  are  removed. 

exit  (E;  £,  n  ::  exit  iC)  — A*  (S',  £)  where  £'  =  updateExit(E,  iC) 

updateExit  performs  two  tasks:  it  removes  the  run-time  instance  from  the  state;  and  removes  from  A4  the 
mapping  from  the  name  of  the  enclosing  application  of  iC  to  a  permission  and  flag  pair  (P,Ptmp)  for  all 
permissions  P  that  were  granted  to  iC.  Note  that  it  does  not  remove  permissions  associated  with  the 
permanent  flag  Tprrn. 

When  the  system  reboots,  all  the  run-time  components  are  deleted,  and  the  auxiliary  data  structure  is 
reset  to  be  an  empty  map. 

reboot  ((M,C  1,  ■  •  •  ,Cn,iG i,  •  •  •  ,  iCn)\£,n  ::  reboot)  ((0,0 1,  •  •  •  ,On);0) 

3  Security  Properties 

We  define  several  properties  that  one  might  desire  of  an  Android-style  security  architecture  (§3.1)  and 
investigate  whether  they  currently  hold  (§3.2). 

3.1  Specifying  Desired  Security  Properties 

We  formulate  the  properties  desired  of  Android’s  security  architecture  based  on  the  resources  that  need 
protection.  These  are  typically  interfaces  that  allow  access  to  functionality  that  could  cause  harm  or  incon¬ 
venience  (e.g.,  sending  expensive  text  messages)  and  to  sensitive  data  that  should  not  leave  the  possession  of 
components  that  legitimately  require  it  (e.g.,  financial  information  in  a  banking  application;  location  infor¬ 
mation).  We  abstractly  define  access-control  properties  that  specify  when  and  how  a  protected  interface  can 
be  called  and  information-flow  properties  that  specify  when  and  what  information  can  flow  to  or  from  a  com¬ 
ponent.  We  also  investigate  lower-level,  functional-correctness  properties  concerning  granting  and  revoking 
permissions,  since  these  directly  affect  the  access-control  and  information-flow  properties. 
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Local  properties  The  following  two  properties  state  that  the  immediate  restrictions  specified  by  a  com¬ 
ponent  on  its  callers  or  callees  are  always  obeyed. 

Property  1.  (Local  callee  protection)  If  a  component  A  is  called  by  another  component  B,  then  A ’s  guard 
PckCaiiee  evaluates  to  true. 

Property  2.  (Local  caller  protection)  If  a  component  A  calls  another  component  B,  then  A’s  guard 
VckCaiier  evaluates  to  true. 

It  is  easy  to  show  that  Prop.  1  and  2  hold  on  any  instantiation  that  includes  rules  like  call-t  and  call-f 
(see  §2.2). 


Delegation  and  revocation  properties  Property  3.  (Delegation)  A  component  A  has  a  permission 
P  if  A  owns  P,  or  there  is  a  delegation  chain  from  a  component  B  to  A  such  that  A  satisfies  the  scope  and 
lifetime  constraints  imposed  by  every  component  on  the  chain,  and  that  every  component  on  the  chain  also 
has  P. 

1.  A  owns  P  or  A  is  granted  P  by  the  user;  or 

2.  (a)  there  exists  a  delegation  chain  that  ends  with  A  s.t.  for  all  B  in  the  chain  (where  B  7^  A): 

i.  B  has  P,  and 

ii.  A  satisfies  the  scope  and  lifetime  constraints  imposed  by  B; 

(b)  and  P  has  not  been  revoked  from  A. 

Intuitively,  Prop.  3  ensures  that  the  use  of  a  redelegated  permission  is  confined  by  the  lifetime  and 
scope  constraints  specified  by  the  original  granter.  For  instance,  if  an  email  component  gives  to  a  viewer 
component  the  URI  permission  P  for  displaying  an  attachment,  two  sensible  constraints  are  that  P  is  confined 
to  a  specific  instance  of  the  viewer,  and  that  the  viewer  cannot  redelegate  P. 

Property  4.  (Revocation)  If  A  revokes  P  from  B,  then  there  is  a  delegation  chain  from  A  to  B,  or  A 
owns  P. 

This  is  a  basic  correctness  property  for  revocation.  Allowing  arbitrary  components  to  revoke  permissions 
is  likely  to  be  disruptive;  hence,  only  the  owner  or  granter  should  be  allowed  to  revoke  a  permission. 

Global  properties  The  next  two  properties  are  simplified  noninterference.  We  customize  the  general 
notion  that  secret  inputs  cannot  affect  public  outputs  and  tainted  inputs  cannot  affect  endorsed  outputs  to 
fit  the  permission-based  Android  model. 

Property  5.  (Privilege  escalation)  Given  any  component  B  protected  by  permission  P ,  and  any  component 
A  that  does  not  have  that  permission,  if  Sab  is  a  system  that  contains  A  and  B  (and  other  components), 
and  Sb  is  the  same  system  without  A,  then  a  call  chain  ending  with  B  exists  in  Sab  if  and  only  if  it  exists 
in  Sb-  Additional  call  chains  ending  with  B  may  exist  in  Sab  if  explicitly  allowed  by  policy. 

In  other  words,  with  respect  to  accessing  B ,  a  system  with  unprivileged  component  A  should  behave  the 
same  as  a  system  without  A.  The  only  exception  is  if  additional  policy  explicitly  allows  A  to  affect  B. 
Without  such  exceptions,  this  property  would  likely  be  too  restrictive. 

For  example,  let  B  be  the  interface,  guarded  by  permission  P ,  for  rebooting  the  phone.  Suppose  that 
component  C  has  P  (which  allows  it  to  call  B),  and  a  public  interface,  such  that  any  calls  to  that  interface 
will  cause  C  to  call  B.  Then,  a  component  A  that  does  not  have  P  can  indirectly  cause  B  to  be  invoked  by 
calling  C.  C’s  indiscriminate  invocation  of  B  is  an  example  of  the  confused-deputy  problem.  Since  a  trace 
culminating  in  that  invocation  of  B  cannot  exist  in  a  system  without  A ,  Prop.  5  prohibits  this  behavior. 

In  the  other  direction,  we  may  want  to  prevent  sensitive  information  from  being  leaked,  which  permission 
systems  typically  cannot  specify  directly.  We  leverage  permissions  to  state  an  undesired  information  flow  as 
follows.  Suppose  that  permission  Pi  guards  the  source  of  some  information  and  permission  P2  guards  the 
sink.  Then,  an  undesired  information  flow  can  be  specified  as  a  call  chain  from  a  component  that  uses  Pi  to 
a  component  that  uses  P2 .  A  system  that  has  no  undesired  information  flows  should  then  obey  the  following 
property. 
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Property  6.  (Information  flow)  Given  an  undesired  information  flow  from  a  component  A  guarded  by  P\ 
to  a  component  B  guarded  by  P2,  a  call  chain  that  ends  with  B  exists  in  a  system  with  A  if  and  only  if  the 
same  call  chain  exists  in  a  system  without  A.  Additional  call  chains  ending  with  B  may  exist  in  the  system 
with  A  only  if  explicitly  allowed  by  policy. 

Without  a  more  expressive  policy  specification  language,  these  properties  cannot  be  specified  precisely. 

3.2  Analyzing  Android  Permissions 

We  investigated  the  extent  to  which  Android’s  current  permission  system,  as  represented  by  our  model, 
supports  the  properties  defined  in  §3.1. 

Local  properties  hold  Android’s  permission  system  implements  the  CALL-T  and  CALL-F  rules,  and  the 
guards  specified  by  the  components  are  checked  at  run  time;  hence,  Prop.  1  and  2  hold.  However,  Prop.  2 
holds  trivially,  because  callers  cannot  state  useful  guards  on  callees. 

Delegation  and  revocation  properties  do  not  hold  Prop.  3  requires  that  a  permission  does  not  outlive 
the  lifespan  specified  by  its  granter.  Android’s  implementation,  however,  does  not  distinguish  between  Ftmp 
and  J~prm  when  deciding  whether  a  component  can  grant  permissions.  This  violates  Prop.  3  and  causes 
several  bugs  (see  Appendix  A),  e.g.,  a  component  that  gained  temporary  permission  can  redelegate  the 
permission  permanently,  including  to  itself. 

Android’s  revokeURIPermission  revokes  a  URI  permission  from  all  components  to  which  it  was  dynamically 
granted,  and  can  be  called  by  any  component  that  was  granted  the  permission  at  install  time.  This  violates 
Prop.  4,  which  requires  that  a  component  A  can  revoke  only  from  entities  to  which  it  granted  permission 
(unless  A  owns  the  permission).  Such  violations  can  easily  cause  confusion,  as  unrelated  applications  can 
revoke  each  other’s  permissions. 

Global  properties  do  not  hold  Previous  work  has  pointed  out  that  Android  suffers  from  privilege- 
escalation  flaws  (e.g.,  [6]);  i.e. ,  Prop.  5  does  not  hold.  Prop.  6  also  does  not  hold,  as  Android  does  not 
have  a  mechanism  for  preventing,  or  even  specifying,  undesired  information  flows.  An  application  can  access 
any  component  for  which  it  has  the  permission  to  do  so,  regardless  of  whether  it  had  previously  accessed 
protected  information.  Previous  work  has  shown  that  this  results  in  various  specific  undesired  information 
flows  [23,  17,  8], 

Examining  Android  in  light  of  these  properties  also  revealed  several  implementation  bugs  (see  Appendix  A), 
which  we  reported  to  Google. 

4  Sorbet:  Android  PermissionsH — \- 

Motivated  by  the  properties  of  §3.1,  we  develop  Sorbet,  an  improved  permission  system  that  supports  (1) 
developer-defined  policies  to  mitigate  undesired  information  flows  and  privilege-escalation  attacks;  and  (2) 
well-behaved  permission  delegation  and  revocation.  Our  goals  were  to  enable  developers  and  users  to  specify 
richer  policies  on  their  applications  without  dramatically  altering  Android,  and  to  construct  an  enforcement 
system  that  is  provably  well  behaved. 

Some  of  the  mechanisms  we  use  have  been  discussed  previously  [10,  21,  13,  7];  we  integrate  these  and 
other  ideas  into  a  system  that  we  can  formally  show  satisfies  interesting  security  properties  and  enables  new 
use  cases. 

4.1  New  Features  in  Sorbet 

Coarse-grained  information-flow  protection  Sorbet  extends  Android’s  permission  labels  to  make 
them  suitable  for  specifying  coarse-grained  information-flow  policies,  and  enforces  such  policies  at  component 
and  application  boundaries.  By  reusing  permission  labels,  this  approach  requires  little  new  syntax. 


Flag 

Recipient 

Redelegation  scope 

Lifetime 

comp 

activity 

no  redelegation 

activity  exit 

task 

activity 

activities  in  the  same  task 

activity  exit 

app  Tmp 

activity 

activities  in  the  same  app 

activity  exit 

allTmp 

activity 

any  component 

activity  exit 

app 

app 

no  redelegation 

app  uninstall 

all 

app 

unrestricted 

app  uninstall 

Figure  2:  Flags  for  constraining  delegation.  Columns  show  the  recipient  scope,  the  scoping  constraints  of 
redelegation,  and  the  lifetime  of  the  granted  permission. 


In  Sorbet,  a  component  A  guarded  by  P\  (e.g.,  the  contacts  permission)  can  specify  (in  the  application 
manifest)  information-flow  policies  of  the  form  disallow-flow(P!,  P2).  This  indicates  that  any  component 
B  that  made  use  of  P\  to  access  A  cannot  (including  transitively)  use  permission  P2.  A  component  can 
also  request  at  install  time  the  permission  allow-declassify(Pi,  P2)  to  declassify  sensitive  information,  i.e.,  to 
escape  the  restriction  imposed  by  disallow-flow(Pi, P2).  We  formalize  this  mechanism  and  the  property  it 
enforces  in  §4.2  and  §4.3. 

Our  mechanism  can  be  used  by  programmers  to  strengthen  their  own  code  by  separating  trusted  infor¬ 
mation  that  should  remain  internal  to  an  application  from  untrusted  flows  that  may  be  communicated  to  the 
outside,  thereby  decreasing  the  chance  of  the  application  being  misused  by  malicious  ones.  The  mechanism 
can  also  be  used  to  defend  against  malicious  applications  or  developers,  by  specifying  policies  that  should 
hold  between  applications. 

Coarse-grained  privilege-escalation  protection  To  mitigate  the  confused-deputy  problem,  Sorbet 
tracks  the  permissions  of  all  components  on  the  call  stack.  When  a  component  A  is  called,  and  A  is  protected 
by  permission  P,  Sorbet  checks  if  every  component  on  the  call  stack  has  P.  However,  this  is  too  restrictive 
for  practical  use;  e.g.,  an  email  app,  which  needs  to  use  the  INTERNET  permission  to  send  email,  could 
do  so  only  when  started  by  applications  that  have  the  INTERNET  permission.  To  address  this,  Sorbet 
allows  components  to  request  a  privileged  permission  P.  When  a  component  B  has  the  permission  P,  it  is 
permitted  to  call  A  even  when  other  components  on  its  call  stack  do  not  have  P.  P  is  similar  to  the  enable 
privilege  operation  in  Java  stack  inspection.  Other  works  have  also  tracked  the  call  stack  for  similar  purposes 
(e.g.,  [7]);  Sorbet’s  novelty  here  is  in  allowing  developers  to  specify  policies,  and  in  enabling  proofs  that 
this  and  other  design  features  allow  the  system  to  exhibit  desired  properties. 

As  with  information  flow,  Sorbet  protects  against  privilege  escalation  at  both  component  level  and 
application  level.  To  account  for  Android’s  inability  to  completely  mediate  communication  (e.g.,  via  public 
static  fields)  between  components  within  an  application,  the  policy  enforced  at  the  application  level  assumes 
that  component  boundaries  within  an  application  are  not  respected. 

Principled  redelegation  and  revocation  Sorbet  also  addresses  Android’s  problems  with  indiscrimi¬ 
nate  redelegation.  The  challenge  here  is  to  design  a  (correct)  mechanism  to  allow  programmers  to  predictably 
control  delegation  lifetime  and  redelegation  scope.  Building  on  Android’s  notion  of  temporary  and  persistent 
permissions,  we  enable  the  grant  operation  to  precisely  convey  the  intended  scope  of  the  recipient  (a  com¬ 
ponent  or  an  application),  the  scope  of  redelegation  (none,  components  in  the  same  task,  components  in  the 
same  application,  and  unrestricted),  and  the  lifetime  of  the  permission  (until  the  recipient  activity  exits,  or 
is  uninstalled).  For  simplicity,  we  converge  on  six  combinations  of  these  constraints  (summarized  in  Fig.  2), 
which  the  programmer  can  specify  via  flags  passed  as  arguments  to  grant.  The  enforcement  mechanism 
enforces  the  transitive  properties  that  the  constraints  implicitly  require. 

Sorbet  allows  a  component  A  to  revoke  a  permission  P  from  component  B  only  if  A  granted  P  to  B 
(or  A  owns  P).  In  other  words,  the  act  of  delegating  creates  a  new  link  in  a  delegation  chain,  and  revocation 
removes  that  link. 

4.2  Implementation  of  Improvements  in  Abstract  Model 

We  now  describe  Sorbet  as  an  instantiation  of  the  abstract  model. 
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Information-flow  protection  To  enforce  information-flow  policies  specified  by  disallow-flow(Pi,  P2)  and 
allow-declassify(Pi,  P2),  we  augment  the  model  with  an  auxiliary  data  structure  A f,  which  keeps  track  of 
information-flow  constraints.  More  concretely,  A f  maps  a  component  instance  iC  to  the  set  of  information- 
flow  constraints  that  includes  all  such  policies  specified  by  components  in  the  call  chain  before  and  including 
iC. 

We  define  forbidP{Af ,  iC)  to  return  the  set  of  permissions  that  are  forbidden  from  being  used  by  con¬ 
straints  in  A f(iC).  For  instance,  if  AT(iC)  =  {disallow-flow(Pi,  P2)},  then  forbulP  returns  {P2}.  Function 
guardP( £ ,  iC)  returns  the  set  of  permissions  that  guards  the  calls  to  component  iC .  A  successful  call  between 
components  in  the  same  group  can  now  be  defined  as  follows. 

CALL-T  (S ;£,n  ::  call  iCi  iC2  I)  (updateCall('E,  call  iCi  iC2  /);£) 

if  iC2.<pckCaiier(£,  iCi)  =  true  and  iCi.<pckCaiUe( £,  iC2)  =  true 
and  guardPfE,  iC2)  fl  forbidP(Af ,  iC\)  =  0 

The  last  line  is  the  added  check  for  information-flow  policies.  The  call  succeeds  only  if  the  permission 
required  to  access  the  callee  is  not  forbidden  by  the  policy. 

If  the  call  succeeds,  information  will  flow  from  the  caller  to  the  callee,  and  constraints  need  to  be  similarly 
propagated.  In  addition,  the  callee  has  its  own  constraints  that  need  to  be  incorporated  in  Af.  For  this, 
we  define  two  new  functions.  updFlow(Af,  iC ,  Fl)  returns  a  new  mapping  A/7,  where  Af'(iC)  =  Af(iC)  U  Fl. 
updDeclassify(Af ,  iC ,  allow-declassify(P1,  P2))  returns  a  new  mapping  A f ,  which  removes  disallow-flow(P!,  P2) 
from  A f  for  iC .  Hence,  after  a  declassification  permission  allow-declassify(P1,  P2)  is  encountered,  the  con¬ 
straint  that  forbade  access  to  components  guarded  by  P2  is  lifted.  E.g.,  if  the  user  explicitly  allows  access 
to  the  Internet  after  private  data  is  read,  then  this  will  be  allowed. 

We  define  function  flowP( X,  iC)  to  return  the  set  of  information-flow  constraints  that  guard  the  calls  to 
iC ,  and  getDeclassify(iC)  to  return  the  set  of  declassification  permissions  of  iC.  The  function  updateCall 
first  computes  A/7  =  updFlow(Af,  iC2,  flowP(T,,  iC\)),  then  A f"  =  updFlow(AF ,iC2,Af \iC\)),  and  finally 
Af'"  =  updDeclassify(Af" ,  iC2,  getDeclassify(iC2)). 

Since  Android  cannot  mediate  all  communication  between  components  within  the  same  application,  a 
cross-application  call  needs  to  conservatively  assume  that  components  within  an  application  have  communi¬ 
cated.  Hence,  we  treat  such  calls  differently.  We  write  A/a(*C)  to  be  the  union  of  sets  of  information-flow 
constraints  A f(iC'),  for  each  iC'  that  is  in  the  same  application  as  iC.  We  define  forbidPA(Af,  iC )  =  A/^zC). 
We  define  function  guardPA(Y,,  iC)  to  return  the  set  of  permissions  that  guards  the  calls  to  all  components 
in  the  same  application  as  component  iC.  In  the  rule  for  cross-application  calls,  A/a  takes  the  place  of  Af , 
and  guardPA  takes  the  place  of  guardP.  This  means  that  if  any  component  in  an  application  has  accessed 
private  data  protected  by  disallow-flow(Pi,  P2),  then  no  component  in  that  application  can  use  permission 
P2.  The  update  function  similarly  accumulates  all  constraints  in  the  entire  application,  rather  than  just  one 
component. 

Returns  are  treated  similarly  to  calls,  with  the  caller  and  callee  designations  switched. 

Privilege-escalation  protection  To  prevent  privilege  escalation,  we  use  auxiliary  tree-like  data  struc¬ 
tures  to  keep  track  of  the  full  call  history.  We  define  a  call  forest  7s  as  a  list  of  call  trees  T,  as  follows: 

Call  Forest  Ts  ::=  [Ti,---,Tn]  Call  Tree  T  ::=  ( Ts,{iC,V )) 

We  use  A4T s  to  denote  a  mapping  from  run-time  components  to  call  forests.  Each  call  tree  represents  a 
call  chain,  and  the  root  of  the  tree  is  the  last  component  on  the  call  chain.  The  child  of  the  root  is  a  call 
forest,  which  is  a  list  of  call  chains,  each  representing  a  past  call  chain  to  the  root  component.  If  component 
A  (which  has  permissions  Pa)  calls  B  (with  permissions  Pb),  and  C  (with  permissions  Pc)  also  calls  B , 
and  B  has  only  one  run-time  instance,  then  MT s{B)  =  [([],  (A,  Pa)),  ([],  (C,  Pc))]-  In  other  words,  each 
call  tree  in  the  call  forest  A4T s{B)  records  the  full  context  of  the  call  stack.  If  B  now  calls  D1  the  call  tree 
([([],  (A,P.4)),  ([],  (C,  Pc))],  (P,Pe))  Will  be  stored  in  MTS(D). 

A  call  from  component  A  to  component  B  is  allowed  only  when  for  any  permission  P  that  guards  the 
access  to  B,  either  A  has  P;  or  A  has  P  and  for  every  call  chain  recorded  in  AATs(A),  either  (1)  all 
the  components  have  permission  P;  or  (2)  there  exists  a  component  C  that  has  permission  P,  and  all  the 
components  in  the  call  stack  after  C  have  P. 
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Given  the  definitions  of  T  and  7s,  we  define  functions  checkPF(Ts,  P)  and  checkP(T,  P)  recursively. 
checkPF(Ts,  P)  returns  true  if  for  each  individual  call  stack  in  7s,  it  is  the  case  that  either  (1)  all  the 
components  have  permission  P ,  or  (2)  there  exists  a  component  C  that  has  permission  P,  and  all  the 
components  in  the  call  stack  after  C  have  P.  Similarly,  checkP(T,P)  returns  true  if  the  above  condition 
holds  for  the  call  tree  T.  We  show  the  definitions  below. 

checkPF(Ts ,  P)  =  true  checkP(T ,  P)  =  true 

checkPF(\\,P)  =  true  checkPF  (Ts@[T],  P)  =  true 

P  €  Pc  and  checkPF (Ts ,  P)  =  true  or  P  G  Pc 

checkP((Ts,  ( iC ,  Pc)),  P)  =  true 

We  define  a  function  PermOf  (iC ,  E)  to  return  the  set  of  permissions  of  a  run-time  component  iC  in  state 
E.  We  define  MT(iC,  E)  to  return  the  call  tree  rooted  at  iC.  MT{iC,Y>)  =  (MTs{iC),  (iC,  PermOf  (iC,  E)). 
We  define  the  rule  for  a  successful  call  below. 

CALL-T  (E ;£,n  ::  call  iCi  i<72  /)  °-^  {updateCall{ S,  call  i<7i  iC2  I)\£) 
if  iC2.<PckCaiier(£,  iCi)  =  true,  iCi.ipckCaiieeCE,  iC2)  =  true, 
and  VP  €  guardP(E,iC2),  checkP(MT(iCi,Y),  P)  =  true 

The  last  line  contains  the  additional  checks  for  potential  privilege  escalation.  The  call  will  succeed  only  if 
all  the  components  on  the  call  stack  have  the  permission  P  required  to  access  the  callee.  We  assume  that 
checking  whether  C\  has  the  permissions  that  C2  requires  is  specified  in  (pckCaiier ■ 

If  a  call  is  successful,  we  need  to  update  the  call  forest  mapping  MT s  of  the  callee.  We  define  a  function 
updCallF(MTs,iCi,iC2)  to  update  the  call  forest  map  when  iC\  calls  or  returns  to  iC2.  It  will  return  a 
new  map  MT'g  derived  from  MT s  except  that  MT's(iC2)  =  MTs{iC2)@{(MT(iC\,  E))],  where  @  is  the 
list-concatenation  operation. 

The  updateCall  function  will  call  the  updCallF  function.  As  before,  a  return  is  treated  as  a  call  in  the 
opposite  direction.  We  omit  the  definitions  here. 

For  cross-application  calls,  as  with  information-flow  protection,  we  need  to  consider  the  call  history 
of  all  components  in  the  callee’s  application.  We  define  MT s A  to  return  the  concatenation  of  all  the 
call  trees  MT(iC' ),  where  iC'  and  iC  belong  to  the  same  application.  We  define  MTa^C,  E)  to  re¬ 
turn  the  call  tree  rooted  at  iC  and  the  call  forest  contains  the  call  forest  MT a{iC ,  E):  MT a{iC ,  E)  = 
(MTsA{iC)@MTs{iC),(iC,  PermOf  (iC,Y,)).  In  the  cross-application  call,  MT  is  replaced  with  MT  a- 

4.3  Properties 

We  prove  Sorbet  obeys  Prop.  1-6.  Here  we  show  only  the  more  concrete  restatements  of  Prop.  5  and  6 
made  possible  by  Sorbet’s  new  policy  statements  (disallow-flow,  allow-declassify,  and  P),  and  proof  sketches 
of  Prop.  6  and  Prop.  5. 

We  first  define  an  indirect  call  chain. 

Definition  1.  (Indirect  call  chain)  Given  components  A  and  B ,  there  exists  an  indirect  call  chain  from  A 
to  B  if  there  exist 

1.  components  D i,  •  •  •  ,  D and 

2.  call  chains  from  A  to  D\,  from  D\  to  D2,  ■  ■  ■ ,  and  from  Dk  to  B. 

We  say  that  a  component  A  can  influence  another  component  B  if  there  is  an  indirect  call  chain  from  A 
to  B.  For  example,  A  can  affect  the  behavior  of  B  (i.e. ,  the  intents  that  B  sends)  if  either  (1)  A  is  part  of  a 
call  chain  to  B ,  or  (2)  A  appears  in  a  call  chain  to  some  component  7),  and  this  chain  shares  a  component 
with  a  different  call  chain  to  B.  The  shared  component  carries  A’s  influence  to  B. 

Property  5*.  (Privilege  escalation  (2))  Given  a  component  B  protected  by  permission  P ,  and  a  component 
A  that  does  not  have  P  and  belongs  to  a  different  application  than  B,  if  Sab  is  a  system  that  contains  A 
and  B  (and  other  components),  and  Sb  is  the  same  system  without  A,  then  a  (possibly  indirect)  call  chain 
that  ends  in  B  exists  in  Sab  if  md  only  if  it  exists  in  Sb-  Additional  (possibly  indirect)  call  chains  may 
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exist  in  Sab  only  if  each  such  chain  has  a  common  suffix  with  a  (possibly  indirect)  call  chain  from  A  to  B, 
and  there  exists  a  component  between  A  and  B  that  has  permission  P;  or  there  is  a  component  B'  between 
A  and  B,  the  path  between  B  and  B'  contains  components  of  the  same  application,  and  B'  is  not  protected 
by  permission  P  but  communicated  to  B  via  unmonitored  channels. 

Property  6*.  (Information  flow  (2))  Suppose  a  component  A  is  guarded  by  permission  Pi  and  an  information- 
flow  policy  disallow-flow(Pi, P2),  and  a  component  B  is  guarded  by  P2,  and  A  and  B  belong  to  different 
applications.  Then,  a  ( possibly  indirect)  call  chain  that  ends  with  B,  in  a  system  with  A,  exists  if  and  only 
if  the  same  call  chain  exists  in  a  system  without  A.  Additional  (possibly  indirect)  call  chains  may  exist  in 
the  system  with  A  only  if  each  such  chain  has  a  common  suffix  with  a  (possibly  indirect)  call  chain  from  A 
to  B,  and  there  exists  a  component  between  A  and  B  that  has  permission  allow-declassify(P1,  P2). 

We  formally  define  a  call  graph  G  to  capture  all  the  call  history  as  the  system  executes.  Each  node  in 
the  graph  is  a  pair  of  a  component’s  run-time  instance  iC ,  and  relevant  data  structures  A  at  the  time  the 
node  is  created.  The  edges  of  the  graph  capture  all  three  kinds  of  information  sharing:  direct  call  via  intent, 
instance  sharing;  and  unmonitored  communication  between  components  from  the  same  application. 

Proof  sketch  of  Prop.  5  We  instantiate  A  in  each  node  (G,  A)  of  G  as  the  tuple  (P,  77,7s),  where  R  is 
the  set  of  permissions  that  C  requires  the  caller  to  have,  H  is  the  set  of  permissions  that  C  has,  and  7s  is  a 
call  forest  such  that  7s  =  MT s(C)  at  the  time  of  the  call. 

Given  an  indirect  call  chain  t  in  Sab  that  ends  in  B ,  we  construct  the  call  graph  Gb  ,  which  is  the  subgraph 
of  G  such  that  there  is  a  path  from  every  node  to  a  node  Vb  =  (B,  A).  By  definition,  all  components  that 
could  have  influenced  the  call  to  B  are  included  in  this  graph.  If  Gb  does  not  contain  A  then  the  call  graph 
is  also  a  valid  call  graph  in  system  Sb,  and  Prop.  5  holds.  Otherwise,  let  pab  be  the  path  from  va  to  vb, 
where  va  =  ( A ,  A^).  It  must  be  the  case  that  pab  overlaps  with  t,  since  vb  is  a  shared  node. 

Let  pb  be  the  longest  suffix  of  pab  such  that  all  the  nodes  in  ps  belong  to  the  same  application. 

We  first  show  that  the  call  forest  (7s)  in  the  first  node  in  ps  contains  a  path  p'A ^  that  contains  node  va, 
and  all  the  nodes  in  pab  that  have  at  least  one  direct  neighbor  in  pab  that  belongs  to  a  different  application. 

By  the  definition  of  cross-application  communication,  all  the  edges  in  p ^  are  mediated  by  the  activity 
manager.  Such  a  path  p exists  because  the  rule  for  cross-application  communication  takes  all  the  call 
forests  of  the  components  from  the  caller’s  application  as  the  caller  component’s  call  forest,  which  in  effect 
assumes  that  there  is  a  direct  call  edge  from  every  component  in  that  application  to  the  caller  component. 

Next  we  show  by  induction  on  the  length  of  ps  that  either  there  is  a  component  between  va  and  vb 
that  contains  P,  or  there  exists  a  B'  such  that  the  edge  between  B'  and  B  is  unmonitored,  and  B'  is  not 
protected  by  P. 

In  the  base  case,  when  \pn\  =  1,  B  is  the  only  node  in  ps-  By  the  reasoning  above,  we  know  that  there 
exists  p'ab  in  the  call  forest  of  B  such  that  A  is  the  first  node.  By  the  definitions  of  rules  call-t,  call-f, 
ret-t  and  ret-f,  if  the  call  to  B  succeeded,  then  it  must  be  the  case  that  checkPF (Ts ,  P)  returned  true, 
where  7s  was  the  call  forest  at  node  vb-  This  means  that  there  is  a  component  C  on  the  path  p'^  that  has 
P;  otherwise  the  check  would  have  failed.  Hence,  Prop.  5  holds. 

In  the  inductive  case,  \pb\  =  n.  There  are  two  subcases.  In  the  first  subcases,  ps  does  not  contain  any 
unmonitored  edges.  In  this  case,  the  call  forest  stored  at  B  would  have  included  p'ab-  Using  similar  reasoning 
as  above,  there  is  a  component  C  on  the  path  p that  has  P;  otherwise  the  check  would  have  failed. 

In  the  second  subcase,  let  B'  be  the  closest  node  to  B  on  pB  such  that  the  edge  between  B'  and  B  is 
unmonitored.  If  B'  is  not  protected  by  P,  then  conclusion  holds.  Otherwise,  the  length  of  the  prefix  of  ps 
ending  with  B'  is  smaller  than  n,  and  we  can  apply  induction  hypothesis  directly. 

Therefore,  Prop.  5  holds. 

Proof  sketch  of  Prop.  6  Here  the  data  structure  A  at  each  node  stores  forbidden  permissions  at  the  time 
the  node  is  created.  Given  the  call  graph  G,  we  can  identify  the  subgraph  Gb  containing  all  the  (indirect) 
call  chains  that  reach  B.  If  Gb  does  not  contain  A ,  then  this  subgraph  is  also  valid  in  the  system  without  A. 
Hence,  the  conclusion  holds.  If  Gb  contains  A,  there  must  be  a  path  from  A  to  B.  In  this  case,  we  prove  two 
statements  inductively:  (1)  If  there  is  an  indirect  call  chain  from  A  to  X ,  X’s  enclosing  application  is  XA, 
and  some  of  the  components  in  XA  use  P2,  then  P2  cannot  be  in  the  forbidden  permission  set  of  any  of  the 
components  in  XA  on  this  path,  and  there  must  be  a  component  that  has  allow-declassify(Pi,  P2)  between  A 
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Figure  3:  Sorbet  architecture:  Sorbet’s  additions  to  Android  are  shaded;  arrows  indicate  interactions 
between  components;  and  dashed  arrows  are  present  in  Android  but  unneeded  in  Sorbet. 


and  X  (not  including  X)\  (2)  If  there  is  an  indirect  call  chain  from  A  to  X,  X’s  enclosing  application  is  X A, 
and  P2  is  not  in  the  forbidden  permissions  of  any  of  the  components  in  XA;  then  there  must  be  a  component 
between  A  and  X  (inclusive)  that  has  allow-declassify(Pi,  P2).  When  proving  these  two  statements,  we  apply 
mutual  induction  on  the  length  of  the  trace.  The  main  idea  is  that  the  unmonitored  communication  will 
not  change  the  invariant  of  the  conditions,  since  we  make  a  uniform  assumption  about  components  in  the 
same  application.  In  proving  (1),  the  rule  for  cross-application  calls  ensures  that  the  intersection  of  the  sets 
of  permissions  guarding  components  of  the  callee’s  application  and  the  set  of  forbidden  permissions  of  the 
caller’s  application  is  empty.  This  condition  allows  us  to  apply  the  I.H.  of  (2)  right  away. 


5  Implementing  and  Evaluating  Sorbet 

We  implemented  Sorbet  on  top  of  Android  2.3.7.  This  section  describes  the  most  salient  implementation 
details,  including  the  syntactic  additions  for  expressing  Sorbet’s  policies,  and  a  case  study  that  illustrates 
Sorbet’s  features. 

Syntactic  additions  We  extended  Android’s  manifest  file  syntax  to  support  information-flow  and  in¬ 
tegrity  policies.  disallow-flow(P1,  P2)  is  specified  at  the  component  that  is  protected  by  Pi  by  includ¬ 
ing  android:forbiddenPermissions=["P2"]  in  the  list  of  permissions  by  which  a  component  is  protected. 
allow-declassify(Pi,  P2)  is  specified  as  <declassif  ied-inf  o  source=["Pi"]  destination  ["P2 "]  />.  A  permis¬ 
sion  is  labeled  as  privileged  P  by  the  addition  of  a  “privileged”  attribute  to  its  declaration:  <uses-permission 
android : name= " P  "  android : pr ivileged=" true " />. 

Implementation  overview  Sorbet’s  keystone  is  a  reference  monitor  built  on  top  of  Android’s  Activ- 
ityManager  (Fig.  3).  ActivityManager  already  mediates  inter-component  communication,  which  includes 
preventing  calls  that  are  illegal  by  Android’s  policy;  Sorbet  modifies  it  so  that  mediation  of  relevant  calls  is 
handled  by  Sorbet  instead  of  by  the  legacy  parts  of  ActivityManager.  Enforcing  Sorbet’s  policies  also  re¬ 
quires  additional  bookkeeping,  including  of  instance  data  (e.g.,  to  recognize  that  a  particular  application  has 
accessed  a  resource  protected  by  a  “forbidden”  permission),  and  richer  static  policy  specified  in  application 
manifests.  Hence,  a  significant  component  of  Sorbet’s  implementation  is  the  data  structures  that  imple¬ 
ment  this  bookkeeping.  The  bookkeeping  includes  keeping  track  of  individual  files  accessed  by  applications; 
for  enforcement  purposes,  these  are  treated  as  components. 
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Figure  4:  Three  scenarios  from  our  case  study.  Columns  indicate  the  permissions  assigned  to  each  application, 
and  whether  enforcement  is  via  protection  from  privilege  escalation  (PE),  or  information  flow  prevention 
(IF). 

A  particular  challenge  in  implementing  Sorbet  was  to  capture  operations  that  are  not  mediated  by 
ActivityManager,  such  as  opening  a  socket  or  a  file.  Android  enforces  permission-based  policies  on  such 
operations  by  Linux-level  checks  based  on  the  (Linux)  group  ID  of  the  calling  application;  applications 
are  placed  in  the  correct  groups  at  installation  time  by  the  Package  Manager.  To  mediate  access  to  these 
operations,  we  used  TOMOYO  Linux  [20],  a  set  of  Linux  kernel  patches  that  replaces  scattered,  ad-hoc 
access-control  checks  with  centralized  ones.2  We  further  extended  TOMOYO  Linux  so  that  access  attempts 
for  which  policy  was  enforced  at  Linux  level  (e.g.,  to  open  a  socket  or  a  file)  trigger  a  call  to  Sorbet’s 
reference  monitor.  This  also  allows  Sorbet  to  mediate  security-relevant  behaviors  implemented  in  native 
code  that  may  be  included  in  Android  applications. 

Case  study  To  test  Sorbet  and  illustrate  its  usefulness,  we  used  it  to  implement  several  policies;  some 
that  can  be  implemented  (sometimes  partially)  by  previously  proposed  mechanisms  (e.g.,  [2,  7]),  and  some 
that  require  Sorbet’s  features.  Our  main  case  study  involves  four  applications:  a  file  manager  for  storing  and 
manipulating  private  files  (e.g.,  a  diary  or  list  of  account  numbers);  a  text  editor;  an  encryption  application; 
and  an  email  application.  The  high-level  policy  we  focus  on  is  to  prevent  private  files  from  being  leaked  on 
the  Internet,  but  to  allow  them  to  be  manipulated  by  various  applications  at  the  user’s  behest  (e.g.,  by  using 
the  private  file  manager  to  launch  an  editor).  Private  files  are  kept  in  a  content  provider  implemented  by 
the  file  manager,  and  protected  by  separate  permissions  that  allow  read  and  write  access.  Applications  can 
access  private  files  only  when  dynamically  delegated  the  appropriate  permissions  by  the  file  manager.  We 
next  describe  several  specific  scenarios  (summarized  in  Fig.  4)  that  examine  variants  of  this  policy  and  show 
how  they  could  be  implemented. 

Scenario  1.  We  start  from  a  base  case  in  which  private  files  must  not  be  sent  over  the  network  (Fig.  4, 
Scenario  1).  In  Android,  the  only  way  to  prevent  one  of  these  applications  from  leaking  files  to  the  network 
is  to  avoid  granting  any  of  the  applications  the  Internet  permission  (Scenario  la).  In  Sorbet,  this  policy  can 
be  enforced  by  either  the  mechanism  that  prevents  privilege  escalation  or  the  one  that  prevents  undesired 
information  flows.  In  the  first  case,  all  other  applications  can  be  granted  the  Internet  permission,  but  will  no 
longer  be  able  to  use  it  if  the  file  manager,  which  does  not  have  this  permission,  is  on  the  call  stack  (Scenario 
lb).  In  the  second  case,  the  file  manager  declares  the  Internet  permission  as  forbidden,  with  the  same  effect 
(Scenario  lc). 

Scenario  2.  We  now  extend  the  desired  policy  to  allow  only  the  email  client  to  send  a  private  file  (an 
activity  that  the  user  explicitly  initiates),  while  other  applications  can  use  the  Internet  for  other  purposes. 
This  cannot  be  implemented  in  stock  Android,  but  can  still  be  done  with  either  of  Sorbet’s  protection 
mechanisms.  For  enforcement  via  the  privilege-escalation  mechanism,  the  email  app  must  declare  and  be 
granted  the  privileged  version  of  the  Internet  permission. 

2  TOMOYO  Linux  has  similarly  been  used  by  other  researchers  [2], 
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To  enforce  the  same  policy  via  Sorbet’s  information-flow  mechanism,  the  file  manager  would  declare  the 
Internet  permission  as  forbidden  (as  in  Scenario  1),  and  the  email  would  declare  the  permission  to  declassify 
from  R/W  to  Internet. 

Scenario  3.  Finally,  we  extend  the  policy  from  Scenario  2  to  allow  emailing  private  files  only  if  they  are 
encrypted.  Enforcing  this  without  limiting  reasonable  uses  of  the  email  app  requires  both  the  information- 
flow  and  privilege-escalation  mechanisms.  As  in  Scenario  2a,  the  email  app  is  given  the  privileged  Internet 
permission,  so  that  it  can  send  email  even  if  indirectly  invoked  by  the  file  manager,  which  does  not  have 
the  Internet  permission.  In  addition,  the  file  manager  declares  the  Internet  permission  forbidden,  and  the 
encryption  app  is  allowed  to  declassify.  Now,  the  only  path  to  emailing  private  files  is  via  the  encryption 
app,  which  is  trusted  to  invoke  the  email  app  only  with  encrypted  data. 

The  last  scenario  shows  that  Sorbet  allows  straightforward  specification  of  useful  policies  that  go  sig¬ 
nificantly  beyond  what  Android  offers.  Our  case  study  used  minimally  modified  off-the-shelf  applications: 
Open  Manager  v2.1.8,  Qute  Text  Editor  vO.l,  Android  Privacy  Guard  vl.0.9,  Email  v2.3.4.  We  modified 
their  manifest  files,  added  sending  functionality  to  some,  and  added  a  private  content  provider  to  Open 
Manager.  The  impact  of  Sorbet  on  performance  was  sufficiently  small  to  be  unobservable  by  the  user.3 

6  Related  Work 

Researchers  have  analyzed  the  security  of  Android’s  permission  system  [5,  10],  developed  analysis  tools  for 
Android  applications  [11],  and  proposed  new  protection  mechanisms  (e.g.,  [19,  21]).  Many  works  studied  the 
attack  surface  against  Android  (e.g.,  [18]),  including  attacks  using  covert  and  overt  channels  [23],  DoS  [1] 
and  web  attacks  [16],  and  unauthorized  application  repackaging  [26]. 

Several  works  have  pointed  out  flaws  of  the  current  Android  permission  system.  One  weakness  is  the 
lack  of  global  properties:  Android’s  permission  system  does  not  prevent  privilege  escalation  or  information 
leakage.  Davi  et  al.  [6]  and  Felt  et  al.  [12]  have  studied  privilege-escalation  attacks  in  detail.  Bugiel  et 
al.  developed  a  system  that  monitors  interactions  between  applications  at  runtime  and  has  the  capacity  to 
mitigate  a  wide  range  of  privilege  escalation  attacks  [2] .  Our  enforcement  mechanism  has  many  similarities  to 
theirs.  However,  we  focus  on  allowing  developers  to  specify  policies  on  a  per-application  basis,  and  emphasize 
formal  analysis  of  mechanisms.  Dietz  et  al.  proposed  a  framework  for  provenance  tracking  to  mitigate  the 
confused  deputy  problem  [7].  Our  goals  are  similar,  though  Sorbet’s  mechanism  differs  in  several  ways: 
we  do  not  track  full  provenance  information,  but  instead  focus  on  flexible  policy  specification  based  on 
permissions,  and  we  rely  on  the  Android  runtime  for  bookkeeping,  rather  than  using  digital  signatures. 
Another  proposal  for  mitigating  unintended  application  collusion  is  through  domain  isolation.  Bugiel  et 
al.  assigned  trust  levels  to  applications,  allowing  applications  to  communicate  only  if  they  are  at  the  same 
level  [3].  They  focus  on  defining  policy  for  a  set  of  applications  that  consist  a  trust  level,  whereas  we  let 
applications  define  policy  individually. 

Several  works  have  identified  the  problem  of  privacy  leaks  in  Android  [8,  23,  4,  9].  We  provide  a  formal 
infrastructure  which  allows  these  and  other  flaws  to  be  seen  as  violations  of  desired  security  properties. 
Projects  such  as  TaintDroicl  [8]  and  AppFence  [13]  aim  to  automatically  detect  and  prevent  dangerous 
private  information  leaks  in  Android.  Our  work  is  in  several  ways  complementary  to  these.  TaintDroid  and 
AppFence  operate  at  a  much  finer  granularity,  tracking  tainting  at  the  level  of  variables,  and  enforce  fixed 
policies.  In  contrast,  our  enforcement  is  at  the  component  level,  and  allows  developers  to  specify  policies, 
including,  e.g.,  declassification,  which  is  key  to  enabling  applications  that  have  legitimate  reason  to  send 
tainted  data  to  operate.  We  also  formally  prove  that  our  enforcement  mechanism  soundly  enforces  desired 
high-level  security  properties. 

Formal  analysis  of  Android-related  security  issues  has  received  less  attention.  Shin  et  al.  [24]  developed 
a  formal  model  in  order  to  verify  functional  correctness  properties  of  Android,  which  revealed  a  flaw  in  the 
naming  scheme  for  permissions  and  a  possible  attack  [25].  In  contrast,  our  work  develops  a  more  abstract 
model  suitable  for  reasoning  about  extensions  to  Android’s  permission  system. 

1  We  ran  microbenchmarks,  but,  as  common  in  this  setting,  the  small  changes — and  sometimes  improvements — in  latency 
were  dwarfed  by  the  variances  between  runs. 
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7  Conclusion 


In  addition  to  developing  a  framework  for  formally  analyzing  Android-style  permission  systems,  this  paper 
shows  that  it  is  possible  to  enhance  Android’s  permission  system  to  support  rich  policies  while  maintaining 
convenient,  application-centric  policy  specification.  We  have  proved  the  design  of  our  enforcement  system 
satisfies  a  set  of  security  properties,  showed  its  feasibility  by  implementing  and  running  it  on  a  Nexus  S  phone, 
and  demonstrated  its  usefulness  through  a  case  study.  In  developing  our  system  we  discover  that  Android’s 
inability  to  provide  strong  isolation  between  components  constrains  the  expressiveness  of  our  system  and 
complicates  its  implementation.  Our  system  successfully  provides  both  application-  and  component-level 
protections,  but  component-level  protection  would  be  enhanced  by  stronger  underlying  abstractions. 
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Appendix 

A  Flaws  Discovered  in  Android 

To  the  best  of  our  knowledge  only  Flaw  4  had  previously  been  reported. 

Flaws  related  to  delegation  and  revocation 

Flaw  1:  A  component  that  has  gained  temporary  permission  can  redelegate  the  permanent  version  of  the 
permission  to  another  application,  or  itself. 

For  example,  a  JPEG  viewer  given  temporary  permission  to  read  an  email  attachment  is  able  to  grant 
itself  permanent  permission  to  read  the  attachment. 
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Flaw  2:  The  revocation  function  revokeURIPermission  revokes  a  specific  URI  permission  from  all  components 
that  were  dynamically  granted  this  permission.  It  can  be  called  by  components  that  own  the  permission  or 
were  granted  the  permission  at  install  time.  This  may  lead  to  confusion. 

Consider  the  scenario  where  the  Contacts  application  delegates  a  URI  permission  to  the  email  client  in 
order  to  send  a  contact  through  email.  Before  the  email  client  completes  this  request,  another  application 
that  has  static  permission  (permission. READ_CONTACTS)  to  read  the  Contacts  application’s  content  provider 
can  revoke  the  permission  from  the  email  client.  This  is  an  unexpected  behavior  for  both  the  Contacts 
application  and  the  email  application  and  can  cause  the  email  application  to  crash. 

Flaw  3:  If  a  component  protected  with  permission  P  is  initiated  by  the  Resolver  activity  then  its  caller  is 
not  constrained  to  have  permission  P. 

The  Resolver  is  a  system  activity  that  presents  the  user  with  a  list  of  applications  that  can  complete  an 
action.  For  example,  if  the  SEND  action  can  be  performed  by  multiple  applications-  like  email,  messaging 
and  social  network  applications — the  Resolver  shows  all  of  them  to  the  user  and  the  user  chooses  which  one 
to  use.  However,  if  any  of  these  activities  was  protected  by  permission  P,  and  a  call  that  will  cause  that 
activity  to  start  is  intercepted  by  the  Resolver,  the  caller  is  not  constrained  to  have  P. 

We  speculate  that  this  behavior  is  allowed  because  the  user’s  action  of  selecting  the  target  for  the  call 
implies  the  user’s  consent  to  the  call  even  if  the  caller  does  not  have  the  required  permission.  In  this  situation 
the  user  is  being  asked,  without  this  being  made  explicit,  to  make  a  policy  decision  that  may  conflict  with 
his  install-time  decision  to  allow  only  specific  applications  access  to  a  protected  component.  This  behavior 
of  the  Resolver  is  not  documented,  and  may  lead  to  a  vulnerability  if  the  user  is  not  careful  enough. 

Flaws  due  to  implementation  error  Along  with  the  high-level  correctness  properties  of  §3.1,  the  imple¬ 
mentation  should  obey  several  low-level  correctness  properties.  The  abstract  model  has  helped  us  to  identify 
these  properties,  and  prompted  us  to  examine  the  Android  implementation  and  discover  several  flaws. 

The  first  correctness  property  concerns  the  naming  scheme  for  permissions:  if  permissions  P  and  P'  are 
deemed  the  same  by  the  implementation,  then  they  must  be  the  same  permission.  In  Android,  permissions 
are  represented  as  strings,  and  any  two  permissions  with  the  same  name  string  are  treated  as  equivalent, 
even  if  they  belong  to  unrelated  applications.  We  will  show  vulnerabilities  partially  caused  by  this  later. 

The  second  correctness  property  requires  system  state  to  be  properly  updated  when  components  exit  or 
are  uninstalled.  More  concretely,  when  an  application  declaring  a  permission  P  is  uninstalled,  P  should  be 
revoked  from  other  applications  that  use  P.  Similarly,  when  an  application  containing  a  content  provider 
is  uninstalled,  any  permissions  for  accessing  this  content  provider  should  be  revoked.  Android  does  not 
implement  these  clean-up  functions  properly.  Combined  with  the  inadequate  identification  of  permissions, 
this  results  in  the  following  vulnerabilities. 

Flaw  4:  Permissions  declared  by  uninstalled  applications  are  not  revoked. 

This  leads  to  a  potential  attack  previously  identified  by  Shin  et  al.  [25].  Suppose  that  a  user  installs  a 
malicious  application  A  that  declares  the  permission  P,  and  a  malicious  application  B  that  uses  it.  After¬ 
wards,  the  user  uninstalls  A  and  installs  an  innocent  application  that  declares  a  permission  with  the  same 
name.  Now,  the  malicious  application  B  can  access  the  innocent  application,  as  it  has  already  been  granted 
the  permission.  This  scenario  is  particularly  problematic  because  an  attacker  can  easily  target  well-known 
applications. 

This  flaw  that  enabled  the  attack  was  claimed  to  have  been  addressed  [25],  but  we  were  still  able  to 
reproduce  it  in  Android  2.3.7. 

Flaw  5:  When  an  application  A  containing  a  content  provider  is  uninstalled,  any  dynamically  granted  URI 
permissions  for  accessing  this  content  provider  are  not  revoked. 

If  the  application  A  is  reinstalled,  it  can  be  accessed  by  the  applications  that  were  previously  granted 
these  permissions.  Additionally,  URI  permissions  may  refer  to  rows  inside  database  tables,  which  they  do 
by  row  index.  Even  if  application  A  is  willing  to  share  the  same  data  with  the  same  applications  after  being 
reinstalled,  old  permissions  that  include  row  indices  may  now  point  to  non-existent  rows  or  rows  that  hold 
different  data.  This  can  cause  confusion  on  the  part  of  the  permission  holder,  and  can  lead  to  an  unintended 
information  leak  by  the  content  provider. 
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Flaw  6:  When  an  application  that  holds  a  URI  permission  is  uninstalled,  the  permission  is  not  revoked;  if 
the  application  is  reinstalled  it  still  holds  the  URI  permission.  To  decide  whether  a  new  application  is  the 
same  as  a  previously  uninstalled  one,  Android  relies  on  the  application’s  self-declared  package  name. 

These  two  design  decisions  can  be  leveraged  by  an  attacker  to  perform  the  following  attack.  Suppose 
that  an  application  A  grants  permission  to  an  innocent  application  B,  which  is  then  uninstalled.  A  malicious 
application  C  is  then  installed,  but  has  the  same  (self-declared)  package  name  as  B.  When  it  is  installed,  C 
gains  all  URI  permissions  that  were  granted  to  B. 
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